Computers that execute collaboration software are well known in the prior art, as illustrated, for example in FIGS. 1A-1C, and described in detail in US Patent Publication 2008/0162551 entitled “METHOD AND APPARATUS FOR PERSISTENT REAL-TIME COLLABORATION” by Geyer et al, published Jul. 3, 2008 which is incorporated by reference herein in its entirety as background.
Specifically, FIG. 1A attached hereto illustrates three client computers (at the top of the figure) connected via a network to a server computer (at the bottom of the figure). The server computer in FIG. 1A executes collaboration software to enable real-time conferencing and content management. The client computers (also called simply “client’) use the server computer (also called simply “server”) to share data and collaborate in real-time. The server allows fine grained sharing of any type of content using generic shared objects (GSO) of the type illustrated in FIG. 1B. The server manages relationships between shared objects; i.e., shared objects could be contained in other shared objects or reference other shared objects. As an example, the server might support hierarchical storage of shared objects similar to a file system.
The prior art server of FIG. 1A includes an access control logic that controls access to and modification of objects within an object database. Coupled to the access control logic is navigation logic which includes a relation database including data defining relationships between the various GSOs stored in the object database. Also coupled to access control logic is a broadcast interface that controls the broadcast of modifications to GSOs to identified interested clients, to facilitate synchronous conferencing between clients sharing objects.
A prior art GSO of FIG. 1B includes a set of general properties and a set of variable properties for content. General properties identify certain attributes of the object, without addressing the particular content of the object. General properties are generally populated by the server (FIG. 1A) when the object is created, and modified by the server in response to specific requests from the clients. Variable properties describe actual content of the data structure. Content is associated with a GSO by adding arbitrary numbers of content identifiers to the GSO. The content identifiers are shown in FIG. 1B as being represented by <name, value> pairs. For example, a GSO may have multiple <name,value> pairs with the same general name, thus defining an ‘activity list’ for the name. For example, a given GSO having a name of ‘Design’ could include one <name, value> pair defining a document to be modified and another <name, value> pair defining a chat session. Members in the access control list of ‘Design’ can simultaneously access the document and chat session to synchronously collaborate on the design. The value field is typically a text field but could optionally also support different data types, e.g. Integer, Boolean etc. In particular, a GSO supports binary content, i.e. the value field could be a large binary object. In general, the value field could support types similar to relational database systems.
As shown in FIG. 1B, associated with each variable property (activity, or item of information) is an access history used to track a member's access to the individual data item, or activity. The access history could take a variety of forms, including an ordered list of members having recent access, the types of the most recent access (modification or simply reading), etc. Also shown in FIG. 1B is an access list in the general properties of the GSO, which is used to manage a list of members having access to the object. Different members having different roles may access objects in different manners. For example, some members may have modify access, whereas some may only have read access. In addition, some members may have no access to particular variable properties in the activity list of the associated with the object.
The prior art server of FIG. 1B supports complex collaboration through the aggregation of GSOs into hierarchies, graphs, or other structures as illustrated in FIG. 1C. Thus, GSOs can have arbitrary pointers to other GSOs. Each GSO within such a structure can have different membership. FIG. 1A's server may provide functions to help manage membership within these structures; e.g. when adding to or removing members from a single GSO, the server might provide options to propagate this operation to related GSOs. Likewise, when adding a new GSO to an existing GSO, the server may support conventions such as: aggregating the member lists of both GSOs, inheriting the member list of the existing GSO, or allowing the member list of the new GSO to prevail.
Prior art collaboration systems may implement attachments between objects as follows: an object M is attached to another object A by storing a pointer 101 to-object M in a field of object A. The current inventors of the invention described below note that such a prior art attachment has several drawbacks. One drawback of such attachment is that any attribute change to-object M after attachment affects any usage of that same object M which predates the attachment. For example, a collaborator (e.g. client) who may have been explicitly denied access to-object M may now gain access via object A and pointer 101.
Hence the current inventors believe that there is a need for a method and apparatus of the type described below.